Using the Properties Assistant, order CreditCard's form property keys as: cardNumber, expirationDate, limit, authorizationNum, authorizationDate, customer.
Note that customer is a to-one relationship from CreditCard to Customer. Ordinarily, a to-one relationship is represented in a form, but customer isn't represented here. That's because Direct to Java Client filters the customer property key out of the user interface rather than display it recursively. Since the CreditCard form is contained within a Customer form, Customer information is already displayed. This feature is called entity hierarchy filtering.
Warning: Be careful about removing relationships from the set of property keys. Even though a relationship isn't necessary for a window you're looking at, it might be needed by another window.
As an example, consider the MovieRole entity, which has to-one relationships to Movie and Talent. Similarly, Movie and Talent have to-many relationships back to their MovieRoles. Since MovieRole is an "other" entity, MovieRole records are manipulated in a master-detail user interface in Movie and Talent form windows. In a Movie form window, the interface for displaying and setting a MovieRole's value uses only the roleName attribute and the talent relationship. Entity hierarchy filtering prevents the interface from using the movie relationship.
When you're looking at the Movie form window, you might consider removing MovieRole's movie relationship from the form task's property keys. It's filtered out, but you might think of removing it anyway for clarity. However, if you remove it, the movie relationship won't be displayed in the Talent form window either. In the Talent window a MovieRole's movie relationship is important information.
